分享人:甘乐
1.背景介绍
2.知识剖析
3.常见问题
4.解决方案
5.编码实战
6.扩展思考
7.参考文献
8.更多讨论
敏捷软件开发（Agile Software Development）初起于上九十年代中期。最早是为了与传统的瀑布软件开发模式（waterfall model）相比较，所以当时的方法叫做轻量级方法（Lightweight methods）。 二十一世纪初，17 位该方法的倡导者建立了敏捷联盟（Agile Alliance），并将该软件开发方法命名为敏捷软件开发过程。
瀑布模式:它是以文档为驱动，在整个开发过程中，开发人员根据需求文档进行开发，一切以文档为依据。
敏捷联盟在成立之初总结了四条基本的价值原则：
一、story讲解
1.1 制作竞品分析PPT，UE全组参与。（用时：根据产品复杂度，0.5-2小时之内）。
1.2 制作产品原型，交由客户看，客户没有异议之后拆story。
1.3 产品在禅道拆分好story，并且定义出优先级，关联需求，后续开发根据优先级进行开发。
1.4 由产品讲解story，前端和后端都参与。（用时：根据产品的复杂度，1-3小时之内）
二、人员划分
2.1 新建wiki项目主页，把PPT和产品原型（HTML文件）上传到wiki。
2.2 根据产品原型，按照模块划分相关负责人，放到wiki。（由项目负责人新建）。
三、做方案设计、定义接口文档
3.1 前端后端相关人员一起，对照原型，根据模块及页面大概定义出接口。( 一个页面中有几个接口，每个接口入参与出参是什么)
3.2 后端每个模块的负责人，根据开会讨论的结果，在wiki上生成标准的接口文档
3.3 将后端做好的接口文档发给前端模块负责人过目，有问题继续修改；没问题开始后续的步骤 。
四、方案设计
后端开发人员，根据原型以及定义的接口，做好方案设计 。
4.1 对有难度或者有疑点的接口，做出方案，尽量给出多个合理方案 。
4.2 每个方案写清楚优点缺点 。
五、方案评审
对做出的方案设计，做方案评审，建议全体人员参与（无论做不做该项目） 。
六、禅道拆分
相关负责人按照优先级顺序，在禅道拆分自己的任务，单个任务最多不要超过4小时，即拆分要详细 。
七、开发
7.1 搭建开发服务器
7.2 开发人员根据禅道上的任务，按时完成自己的开发工作，具体体现到日报上
7.3 每天上午开10分钟左右进度会议，如果有延迟现象出现，拿出解决方案，保证项目按照禅道上的时间点完成
八、阶段测试
与开发并行
每天至少发布一次代码到开发环境，并且保证发布完之后程序没问题
九、性能测试和coderevivew
9.1 对每个接口做好性能测试----每个接口的响应时间不超过200ms，如果有超过的，做优化，尽量缩小到200ms内
9.2 完成codereview，根据codereview结论完成修改
十、压力测试
做好压测报告
十一、 Demo
11.1 Demo流程
发demo申请邮件，收件人包括产品、测试同学、前后端相关开发人员
11.1.2开demo会议.主讲人为某个开发人员, 会议途中产品和测试提出问题
11.1.3发demo结果通知邮件(由产品同学发)
内容包括：1、demo结果 2、如果不通过，有哪些问题
11.1.4如果不通过，召集第二次Demo会议，直到通过为止。第二次会议只需演示之前不通过的部分
11.2 测试
11.2.1demo通过之后，流程1：开发人员对代码打tag; 2.开发人员部署测试环境，部署完成之后发邮件，写明域名；3：交给测试人员进行测试，测试人员发送全体测试周期邮件.
11.2.2测试期间，开发人员要常去禅道看自己的BUG ，及时确认BUG，及时修改
11.2.3修改BUG之后，开发环境前端代码由前端同学自己部署，后端代码由后端同学自己部署测试环境每天的下午6点由后端同学统一部署前后端代码
11.2.4测试完成之后，测试或产品发送上线通知
十二、 发布测试环境、集成测试
禅道上建立bug，测试出bug，指派给相关人员修改
十三、发布线上环境，同时停止开发环境和测试环境
十四、线上监控
错误报告
为什么使用敏捷开发流程?
敏捷开发的优势:
满足用户不断变化的需求是软件开发的长期无法解决的难题之一,经典的瀑布模式在一个迭代周期内表现优异, 但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、 可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应 尽可能短,以便能及时地处理需求变化和用户反馈。
暂无.
常见的敏捷开发流程比较